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Abstract 


This document discusses usage profiles, based on one or more 
authentication mechanisms, which can be used for DNS over Transport 
Layer Security (TLS) or Datagram TLS (DTLS). These profiles can 
increase the privacy of DNS transactions compared to using only 
cleartext DNS. This document also specifies new authentication 
mechanisms -- it describes several ways that a DNS client can use an 
authentication domain name to authenticate a (D)TLS connection to a 
DNS server. Additionally, it defines (D)TLS protocol profiles for 
DNS clients and servers implementing DNS over (D)TLS. This document 
updates RFC 7858. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
https://www.rfc-editor.org/info/rfc8310. 
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Copyright (c) 2018 IETF Trust and the persons identified as the 
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This document is subject to BCP 78 and the IETF Trust’s Legal 
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(https://trustee.ietf.org/license-info) in effect on the date of 
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carefully, as they describe your rights and restrictions with respect 
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the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 


Dickinson, et al. Standards Track [Page 2] 


RFC 8310 Usage Profiles for DNS over (D)TLS March 2018 


Table of Contents 

Dro SERRE ROGUCE DT OMe A A A a Be eh Sia eer eee 4 
DE WESTMAN O LOGY, A Bees oe Ee BiG at hte ried ela ds o tk ISAS E o A RBs he 6 
See HS COD NN 7 
AS DAS CUS SLO Ml sve, dv ay ater iis Syed orn eae ie sy GP ee a Ea 8 
Ss WS AGS: PLOMO A A ecto le ate ares yA teh Gt ews ante Se 8 
Bula DNS RECO TU CAL OM: isora ee Aitete a bak ded so oh J 

6. Authentication in DNS over (D)TLS oia a oie a lies 11 
6.1. DNS-over-(D)TLS Startup Configuration Problems ............ 11 
62). ¡Credential. Verification a a A Swat 12 
6.3. Summary of Authentication Mechanisms .....oooooooooooooo o... 12 
6.4. Combining Authentication Mechanisms .....ooooocooooooooooo... 15 
6.5. Authentication in Opportunistic Privacy ..................- 15 
66% Aüthentication in Strict Privacy isses less sser e 16 
6. Implementation GuUidánde siias e as au a oe E 16 

7. Sources of Authentication Domain Names .....o.oooooooooooooooooo.. 17 
Tato Full. Direct “Contrigútrat VON, cosas a e ida 17 
T23 Direct. Configuration. of ADN OnLy liada ia As 17 
123%, Dynamite: DiISCOVErY OL ADN unta ar as 17 
adds DECO. A o a o ts 18 

8. Credential Verification Based on Authentication Domain Name ....18 
8.1. Authentication Based on PKIX Certificate .................. 18 
Bd DANE weas one deel ieee Bee Sree eee ens ee AS dan BGO a oleate: AA Sah 19 
Sala Ll. Direct. DNS-MEtasQUerTES sss i. eee tcs 20 

852.2. “TLS: DNSSEC Chain EXtensioN eii dog) eee ga cee S78 e 20 

Oe (DEES -Protocol Profile ie sie eo ee aioe eee: a eae eS ea Sei Seed aa 20 
10: IANA Considerations. riada a a Sf ais consi eee Wid Te we Hae! cee 21 
Tvs -security Considerations ii A aah a eer Se ada Scie: a oe he 21 
11.1. Countermeasures to DNS Traffic Analysis .................. 22 

T2 REPELER ia 22 
TZI. “Normative: References a A a 22 
1222: Informative: Reterendeas: ia a bd 24 
Appendix A. Server Capability Probing and Caching by DNS Clients ..26 
ACKNOWLEAGMENES: rro A A A A See! xaee 78 27 
Authors» Addresses A A A go “eh ae oe 27 


Dickinson, et al. Standards Track [Page 3] 


RFC 8310 Usage Profiles for DNS over (D)TLS March 2018 


1. Introduction 


DNS privacy issues are discussed in [RFC7626]. The specific issues 
described in [RFC7626] that are most relevant to this document are 


o Passive attacks that eavesdrop on cleartext DNS transactions on 
the wire (Section 2.4 of [RFC7626]) and 


o Active attacks that redirect clients to rogue servers to monitor 
DNS traffic (Section 2.5.3 of [RFC7626]). 


Mitigating these attacks increases the privacy of DNS transactions; 
however, many of the other issues raised in [RFC7626] still apply. 


Two documents that provide ways to increase DNS privacy between DNS 
clients and DNS servers are 


o "Specification for DNS over Transport Layer Security (TLS)" 
[RFC7858], referred to here as simply "DNS over TLS". 


o "DNS over Datagram Transport Layer Security (DTLS)" [RFC8094], 
referred to here as simply "DNS over DTLS". Note that [RFC8094] 
is an Experimental specification. 


Both documents are limited in scope to communications between stub 
clients and recursive resolvers, and the same scope is applied to 
this document (see Sections 2 and 3). The proposals here might be 
adapted or extended in future to be used for recursive clients and 
authoritative servers, but this application was out of scope for the 
DNS PRIVate Exchange (dprive) Working Group charter at the time this 
document was published. 


This document specifies two usage profiles (Strict Privacy and 
Opportunistic Privacy) for DTLS [RFC6347] and TLS [RFC5246] that 
provide improved levels of mitigation for the attacks described above 
compared to using only cleartext DNS. 


Section 5 presents a generalized discussion of usage profiles by 
separating the usage profile, which is based purely on the security 
properties it offers the user, from the specific mechanism or 
mechanisms that are used for DNS server authentication. The profiles 
described are 


o A Strict Privacy profile, which requires an encrypted connection 
and successful authentication of the DNS server; this mitigates 
both passive eavesdropping and client redirection (at the expense 
of providing no DNS service if an encrypted, authenticated 
connection is not available). 
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o An Opportunistic Privacy profile, which will attempt, but does not 
require, encryption and successful authentication; it therefore 
provides limited or no mitigation for such attacks but maximizes 
the chance of DNS service. 


The above usage profiles attempt authentication of the server using 
at least one authentication mechanism. Section 6.4 discusses how to 
combine authentication mechanisms to determine the overall 
authentication result. Depending on that overall authentication 
result (and whether encryption is available), the usage profile will 
determine if the connection should proceed, fall back, or fail. 


One authentication mechanism is already described in [RFC7858]. 
[RFC7858] specifies an authentication mechanism for DNS over TLS that 
is based on Subject Public Key Info (SPKI) in the context of a 
specific case of a Strict Privacy profile using that single 
authentication mechanism. Therefore, the "out-of-band key-pinned 
privacy profile" described in [RFC7858] would qualify as a "Strict 
Privacy profile" that used SPKI pinning for authentication. 


This document extends the use of authentication based on SPKI 

pin sets, so that it is considered a general authentication mechanism 
that can be used with either DNS-over- (D)TLS usage profile. That is, 
the mechanism for SPKI pin sets as described in [RFC7858] MAY be used 
with DNS over (D)TLS. 


This document also describes a number of additional authentication 
mechanisms, all of which specify how a DNS client should authenticate 
a DNS server based on an "authentication domain name". In 
particular, the following topics are described: 


o How a DNS client can obtain the combination of an authentication 
domain name and IP address for a DNS server. See Section 7. 


o What acceptable credentials a DNS server can present to prove its 
identity for (D)TLS authentication based on a given authentication 
domain name. See Section 8. 


o How a DNS client can verify that any given credential matches the 
authentication domain name obtained for a DNS server. See 
Section 8. 


This document defines a (D)TLS protocol profile for use with DNS; see 
Section 9. This profile defines the configuration options and 
protocol extensions required of both parties to (1) optimize 
connection establishment and session resumption for transporting DNS 
and (2) support all currently specified authentication mechanisms. 
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Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 


Several terms are used specifically in the context of this document: 


o DNS client: A DNS stub resolver or forwarder. In the case of a 
forwarder, the term "DNS client" is used to discuss the side that 
sends queries. 


o DNS server: A DNS recursive resolver or forwarder. In the case of 
a forwarder, the term "DNS server" is used to discuss the side 
that responds to queries. Note that, as used in this document, 
this term does not apply to authoritative servers. 


o Privacy-enabling DNS server: A DNS server that implements 
DNS over TLS [RFC7858] and may optionally implement DNS over DTLS 
[RFC8094]. The server should also offer at least one of the 
credentials described in Section 8 and implement the (D) TLS 
profile described in Section 9. 


o (D)TLS: Used for brevity; refers to both Transport Layer Security 
[RFC5246] and Datagram Transport Layer Security [RFC6347]. 
Specific terms will be used for any text that applies to either 
protocol alone. 


o DNS over (D)TLS: Used for brevity; refers to both DNS over TLS 
[RFC7858] and DNS over DTLS [RFC8094]. Specific terms will be 
used for any text that applies to either protocol alone. 


o Authentication domain name: A domain name that can be used to 
authenticate a privacy-enabling DNS server. Sources of 
authentication domain names are discussed in Section 7. 


o SPKI pin sets: [RFC7858] describes the use of cryptographic 
digests to "pin" public key information in a manner similar to 
HTTP Public Key Pinning (HPKP) [RFC7469]. An SPKI pin set is a 
collection of these pins that constrains a DNS server. 
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Authentication information: Information a DNS client may use as 
the basis of an authentication mechanism. In this context, this 
information can be either 

* an SPKI pin set or 

* an authentication domain name 

Reference identifier: A reference identifier as described in 
[RFC6125], constructed by the DNS client when performing TLS 
authentication of a DNS server. 

Credential: Information available for a DNS server that proves its 
identity for authentication purposes. Credentials discussed here 
include 

* a PKIX certificate 


* a DNSSEC-validated chain to a TLSA record 


but may also include SPKI pin sets. 


3. Scope 


This document is limited to describing 


o 


o 


Usage profiles based on general authentication mechanisms. 


The details of domain-name-based authentication of DNS servers by 
DNS clients (as defined in Section 2). 


The (D)TLS profiles needed to support authentication in 
DNS over (D)TLS. 


such, the following topics are out of scope for this document: 
Authentication of authoritative servers by recursive resolvers. 
Authentication of DNS clients by DNS servers. 


The details of how to perform authentication based on SPKI 
pin sets. This is defined in [RFC7858]. 


Any server identifier other than domain names, including IP 
addresses, organizational names, country of origin, etc. 
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4. Discussion 


One way to mitigate eavesdropping on cleartext DNS transactions by 
passive attackers is to encrypt the query (and response). Such 
encryption typically provides integrity protection as a side effect; 
this means that on-path attackers cannot simply inject bogus DNS 


responses. To also mitigate active attackers pretending to be the 
server, the client must authenticate the (D)TLS connection to the 
server. 


This document discusses usage profiles, which provide differing 
levels of attack mitigation to DNS clients, based on the requirements 
for authentication and encryption, regardless of the context (for 
example, which network the client is connected to). A usage profile 
is a concept distinct from a usage policy or usage model; a usage 
policy or usage model might dictate which profile should be used in a 
particular context (enterprise vs. coffee shop), with a particular 
set of DNS servers or with reference to other external factors. A 
description of the variety of usage policies is out of scope for this 
document but may be the subject of future work. 


The term "privacy-enabling DNS server" is used throughout this 
document. This is a DNS server that 


o MUST implement DNS over TLS [RFC7858]. 
o MAY implement DNS over DTLS [RFC8094]. 


o SHOULD offer at least one of the credentials described in 
Section 8. 


o Implements the (D)TLS profile described in Section 9. 
5. Usage Profiles 


A DNS client has a choice of usage profiles available to increase the 
privacy of DNS transactions. This choice is briefly discussed in 
both [RFC7858] and [RFC8094]. These usage profiles are 


o Strict Privacy profile: The DNS client requires both an encrypted 
and authenticated connection to a privacy-enabling DNS server. A 
hard failure occurs if this is not available. This requires the 
client to securely obtain authentication information it can use to 
authenticate the server. This profile mitigates both passive and 
active attacks, thereby providing the client with the best 
available privacy for DNS. This profile is discussed in detail in 
Section 6.6. 
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o Opportunistic Privacy profile: The DNS client uses Opportunistic 

Security as described in [RFC7435]. 

* "... the use of cleartext as the baseline communication 
security policy, with encryption and authentication negotiated 
and applied to the communication when available." 

As described in [RFC7435], it might result in 

* an encrypted and authenticated connection 

* an encrypted connection 


* a cleartext connection 


depending on the fallback logic of the client, the available 
authentication information, and the capabilities of the DNS 


server. In all these cases, the DNS client is willing to continue 
with a connection to the DNS server and perform resolution of 
queries. The use of Opportunistic Privacy is intended to support 


incremental deployment of increased privacy with a view to 
widespread adoption of the Strict Privacy profile. It should be 
employed when the DNS client might otherwise settle for cleartext; 
it provides the maximum protection available, depending on the 
combination of factors described above. If all the configured DNS 
servers are DNS privacy servers, then it can provide protection 
against passive attacks and might protect against active ones. 


Both profiles can include an initial meta-query (performed using 
Opportunistic Privacy) to obtain the IP address for the privacy- 
enabling DNS server to which the DNS client will subsequently 
connect. The rationale for permitting this for the Strict Privacy 
profile is that requiring such meta-queries to also be performed 
using the Strict Privacy profile would introduce significant 
deployment obstacles. However, it should be noted that in this 
scenario an active attack on the meta-query is possible. Such an 
attack could result in a Strict Privacy profile client connecting to 
a server it cannot authenticate (and therefore not obtaining DNS 
service) or an Opportunistic Privacy client connecting to a server 
controlled by the attacker. DNSSEC validation can detect the attack 
on the meta-query, which may result in the client not obtaining DNS 
service (for both usage profiles), depending on its DNSSEC validation 
policy. See Section 7.2 for more discussion. 


To compare the two usage profiles, Table 1 below shows a successful 
Strict Privacy profile alongside the three possible outcomes of an 
Opportunistic Privacy profile. In the best-case scenario for the 
Opportunistic Privacy profile (an authenticated and encrypted 


Dickinson, et al. Standards Track [Page 9] 


RFC 8310 Usage Profiles for DNS over (D)TLS March 2018 


connection), it is equivalent to the Strict Privacy profile. In the 
worst-case scenario, it is equivalent to cleartext. Clients using 
the Opportunistic Privacy profile SHOULD try for the best case but 
MAY fall back to the intermediate case and, eventually, the worst- 
case scenario, in order to obtain a response. One reason to fall 
back without trying every available privacy-enabling DNS server is if 
latency is more important than attack mitigation; see Appendix A. 

The Opportunistic Privacy profile therefore provides varying 
protection, depending on what kind of connection is actually used, 
including no attack mitigation at all. 


Note that there is no requirement in Opportunistic Security to notify 
the user regarding what type of connection is actually used; the 
"detection" described below is only possible if such connection 
information is available. However, if it is available and the user 
is informed that an unencrypted connection was used to connect to a 
server, then the user should assume (detect) that the connection is 
subject to both active and passive attacks, since the DNS queries are 
sent in cleartext. This might be particularly useful if a new 
connection to a certain server is unencrypted when all previous 
connections were encrypted. Similarly, if the user is informed that 
an encrypted but unauthenticated connection was used, then the user 
can detect that the connection may be subject to active attacks. In 
other words, for the cases where no protection is provided against an 
attacker (N), it is possible to detect that an attack might be 


happening (D). This is discussed in Section 6.5. 
+--------------- +------------ +------------------ +----------------- + 
| Usage Profile | Connection | Passive Attacker | Active Attacker | 
+--------------- +------------ 4+------------------ +----------------- + 
| Strict | A, E | P | P | 
| Opportunistic | A, E | P | P 
| Opportunistic | E | P | N, D 
| Opportunistic | | N, D | N, D | 
+--------------- Ho +------------------ Ho + 
P == Protection; N == No protection; D == Detection is possible; 

A == Authenticated connection; E == Encrypted connection 


Table 1: Attack Protection by Usage Profile and Type of Attacker 
The Strict Privacy profile provides the best attack mitigation and 
therefore SHOULD always be implemented in DNS clients that implement 


the Opportunistic Privacy profile. 


A DNS client that implements DNS over (D)TLS SHOULD NOT be configured 
by default to use only cleartext. 
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The choice between the two profiles depends on a number of factors, 
including which is more important to the particular client: 


o DNS service, at the cost of no attack mitigation (Opportunistic 
Privacy) or 


o Best available attack mitigation, at the potential cost of no DNS 
service (Strict Privacy). 


Additionally, the two profiles require varying levels of 
configuration (or a trusted relationship with a provider) and DNS 
server capabilities; therefore, DNS clients will need to carefully 
select which profile to use based on their communication needs. 


A DNS server that implements DNS over (D)TLS SHOULD provide at least 
one credential (Section 2) so that those DNS clients that wish to use 
the Strict Privacy profile are able to do so. 


5.1. DNS Resolution 


A DNS client SHOULD select a particular usage profile when resolving 
a query. A DNS client MUST NOT fall back from Strict Privacy to 
Opportunistic Privacy during the resolution of a given query, as this 
could invalidate the protection offered against attackers. It is 
anticipated that DNS clients will use a particular usage profile for 
all queries to all configured servers until an operational issue or 
policy update dictates a change in the profile used. 


6. Authentication in DNS over (D)TLS 


This section describes authentication mechanisms and how they can be 
used in either Strict or Opportunistic Privacy for DNS over (D)TLS. 


6.1. DNS-over-(D)TLS Startup Configuration Problems 


Many (D)TLS clients use PKIX authentication [RFC6125] based on an 
authentication domain name for the server they are contacting. These 
clients typically first look up the server's network address in the 
DNS before making this connection. Such a DNS client therefore has a 
bootstrap problem, as it will typically only know the IP address of 
its DNS server. 


In this case, before connecting to a DNS server, a DNS client needs 

to learn the authentication domain name it should associate with the 
IP address of a DNS server for authentication purposes. Sources of 

authentication domain names are discussed in Section 7. 
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One advantage of this domain-name-based approach is that it 
encourages the association of stable, human-recognizable identifiers 
with secure DNS service providers. 


6.2. Credential Verification 
Verification of SPKI pin sets is discussed in [RFC7858]. 


In terms of domain-name-based verification, once an authentication 
domain name is known for a DNS server, a choice of authentication 
mechanisms can be used for credential verification. Section 8 
discusses these mechanisms -- namely, PKIX certificate-based 
authentication and DNS-Based Authentication of Named Entities (DANE) 
-- in detail. 


Note that the use of DANE adds requirements on the ability of the 
client to get validated DNSSEC results. This is discussed in more 


detail in Section 8.2. 
6.3. Summary of Authentication Mechanisms 


This section provides an overview of the various authentication 
mechanisms. Table 2 below indicates how the DNS client obtains 
information to use for authentication for each option: either 
statically via direct configuration or dynamically. Of course, the 
Opportunistic Privacy profile does not require authentication, and so 
a client using that profile may choose to connect to a 
privacy-enabling DNS server on the basis of just an IP address. 
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4---4+------------ +------------- HO + 
| # | Static | Dynamically | Short name: Description 
| | Config | Obtained | | 
+—---+------------ +------------- HO + 
| 1 | SPKI + IP | | SPKI: SPKI pin set(s) and IP 
| | | | address obtained out of band | 
| | | | [RFC7858] | 
| 2 | ADN + IP | | ADN: ADN and IP address obtained | 
| | | | out of band (see Section 7.1) | 
| 3 | ADN | IP | ADN only: Opportunistic Privacy 
| | | | meta-queries to a NP DNS server | 
| | | | for A/AAAA (see Section 7.2) | 
| 4 | | ADN + IP | DHCP: DHCP configuration only (see | 
| | | | Section 7.3.1) | 
| 5 | [ADN + IP] | [ADN + IP] | DANE: DNSSEC chain obtained via | 
| | | TLSA record | Opportunistic Privacy meta-queries | 
| | | | to NP DNS server (see Section | 
| | et | 
| 6 | [ADN + IP] | [ADN + IP] | TLS extension: DNSSEC chain | 
| | | TLSA record | provided by PE DNS server in TLS | 
| | | | DNSSEC chain extension (see | 
| | | | Section 8.2.2) | 
+---+------------ +------------- 4------------------------------------ + 
SPKI == SPKI pin set(s); IP == IP Address; 
ADN == Authentication Domain Name; NP == Network-Provided; 
PE == Privacy-Enabling; [ ] == Data may be obtained either 


statically or dynamically 
Table 2: Overview of Authentication Mechanisms 
The following summary attempts to present some key attributes of each 
of the mechanisms (using the "Short name" from Table 2), indicating 
attractive attributes with a "+" and undesirable attributes 
with a MSs 
Tz SPKI 
+ Minimal leakage (note that the ADN is always leaked in the 
Server Name Indication (SNI) field in the ClientHello in TLS 


when communicating with a privacy-enabling DNS server) 


- Overhead of ongoing key management required 
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2. ADN 

+ Minimal leakage 

+ One-off direct configuration only 
3. ADN only 


+ Minimal one-off direct configuration; only a human-recognizable 
domain name needed 


- A/AAAA meta-queries leaked to network-provided DNS server that 
may be subject to active attack (attack can be mitigated by 
DNSSEC validation) 

4. DHCP 


+ No static config 


- Requires a non-standard or future DHCP option in order to 
provide the ADN 


- Requires secure and trustworthy connection to DHCP server if 
used with a Strict Privacy profile 


5. DANE 


The ADN and/or IP may be obtained statically or dynamically, and 
the relevant attributes of that method apply. 


+ DANE options (e.g., matching on entire certificate) 


- Requires a DNSSEC-validating stub implementation (the 
deployment of which is limited at the time of this writing) 


- DNSSEC chain meta-queries leaked to network-provided DNS server 
that may be subject to active attack 


6. TLS extension 


The ADN and/or IP may be obtained statically or dynamically, and 
the relevant attributes of that method apply. 


+ Reduced latency compared with DANE 


+ No network-provided DNS server required if ADN and IP 
statically configured 
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+ DANE options (e.g., matching on entire certificate) 
- Requires a DNSSEC-validating stub implementation 
6.4. Combining Authentication Mechanisms 


This document does not make explicit recommendations about how an 
authentication mechanism based on SPKI pin sets should be combined 
with a domain-based mechanism from an operator perspective. However, 
it can be envisaged that a DNS server operator may wish to make both 
an SPKI pin set and an authentication domain name available to allow 
clients to choose which mechanism to use. Therefore, the following 
text provides guidance on how clients ought to behave if they choose 
to configure both, as is possible in HPKP [RFC7469]. 


A DNS client that is configured with both an authentication domain 
name and an SPKI pin set for a DNS server SHOULD match on both a 
valid credential for the authentication domain name and a valid SPKI 
pin set (if both are available) when connecting to that DNS server. 
In this case, the client SHOULD treat individual SPKI pins as 
specified in Section 2.6 of [RFC7469] with regard to user-defined 


trust anchors. The overall authentication result SHOULD only be 
considered successful if both authentication mechanisms are 
successful. 


6.5. Authentication in Opportunistic Privacy 


An Opportunistic Privacy Profile (based on Opportunistic Security 
[RFC7435]) that MAY be used for DNS over (D)TLS is described in 
[RFC7858] and is further specified in this document. 


DNS clients that issue queries under an Opportunistic Privacy profile 
and that know authentication information for a given privacy-enabling 
DNS server SHOULD try to authenticate the server using the mechanisms 
described here. This is useful for detecting (but not preventing) 
active attacks, since the fact that authentication information is 
available indicates that the server in question is a privacy-enabling 
DNS server to which it should be possible to establish an 
authenticated and encrypted connection. In this case, whilst a 
client cannot know the reason for an authentication failure, from a 
security standpoint the client should consider an active attack in 
progress and proceed under that assumption. For example, a client 
that implements a nameserver selection algorithm that preferentially 
uses nameservers that successfully authenticated (see Section 5) 
might not continue to use the failing server if there were 
alternative servers available. 
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Attempting authentication is also useful for debugging or diagnostic 
purposes if there are means to report the result. This information 
can provide a basis for a DNS client to switch to (preferred) Strict 
Privacy where it is viable, e.g., where all the configured servers 
support DNS over (D)TLS and successfully authenticate. 


6.6. Authentication in Strict Privacy 


To authenticate a privacy-enabling DNS server, a DNS client needs to 
know authentication information for each server it is willing to 
contact. This is necessary to protect against active attacks that 
attempt to redirect clients to rogue DNS servers. 


A DNS client requiring Strict Privacy MUST use either (1) one of the 
sources listed in Section 7, to obtain an authentication domain name 
for the server it contacts or (2) an SPKI pin set as described in 
[RFC7858]. 


A DNS client requiring Strict Privacy MUST only attempt to connect to 
DNS servers for which at least one piece of authentication 
information is known. The client MUST use the available verification 
mechanisms described in Section 8 to authenticate the server and MUST 
abort connections to a server when no verification mechanism 
succeeds. 


With Strict Privacy, the DNS client MUST NOT commence sending DNS 
queries until at least one of the privacy-enabling DNS servers 
becomes available. 


A privacy-enabling DNS server may be temporarily unavailable when 
configuring a network. For example, for clients on networks that 
require registration through web-based login (a.k.a. "captive 
portals"), such registration may rely on DNS interception and 
spoofing. Techniques such as those used by dnssec-trigger 
[dnssec-trigger] MAY be used during network configuration, with the 
intent to transition to the designated privacy-enabling DNS servers 
after captive-portal registration. If using a Strict Privacy 
profile, the system MUST alert by some means that the DNS is not 
private during such a bootstrap operation. 


6.7. Implementation Guidance 
Section 9 describes the (D)TLS profile for DNS over (D)TLS. 


Additional considerations relating to general implementation 
guidelines are discussed in both Section 11 and Appendix A. 
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7. Sources of Authentication Domain Names 
7.1. Full Direct Configuration 


DNS clients may be directly and securely provisioned with the 
authentication domain name of each privacy-enabling DNS server -- for 
example, using a client-specific configuration file or API. 


In this case, direct configuration for a DNS client would consist of 
both an IP address and an authentication domain name for each DNS 
server that were obtained via an out-of-band mechanism. 


7.2. Direct Configuration of ADN Only 


A DNS client may be configured directly and securely with only the 
authentication domain name of each of its privacy-enabling DNS 
servers -- for example, using a client-specific configuration file 
or API. 


A DNS client might learn of a default recursive DNS resolver from an 
untrusted source (such as DHCP's DNS Recursive Name Server option 
[RFC3646]). It can then use meta-queries performed using an 
Opportunistic Privacy profile to an untrusted recursive DNS resolver 
to establish the IP address of the intended privacy-enabling DNS 
resolver by doing a lookup of A/AAAA records. A DNSSEC-validating 
client SHOULD apply the same validation policy to the A/AAAA 
meta-queries as it does to other queries. A client that does not 
validate DNSSEC SHOULD apply the same policy (if any) to the A/AAAA 
meta-queries as it does to other queries. Private DNS resolution can 
now be done by the DNS client against the pre-configured privacy- 
enabling DNS resolver, using the IP address obtained from the 
untrusted DNS resolver. 


A DNS client so configured that successfully connects to a privacy- 
enabling DNS server MAY choose to locally cache the server host IP 
addresses in order to not have to repeat the meta-query. 


7.3. Dynamic Discovery of ADN 


This section discusses the general case of a DNS client discovering 
both the authentication domain name and IP address dynamically. At 
the time of this writing, this is not possible by any standard means. 
However, since, for example, a future DHCP extension could (in 
principle) provide this mechanism, the required security properties 
of such mechanisms are outlined here. 
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When using a Strict Privacy profile, the dynamic discovery technique 
used as a source of authentication domain names MUST be considered 
secure and trustworthy. This requirement does not apply when using 
an Opportunistic Privacy profile, given the security expectation of 
that profile. 


dk DHCP 


In the typical case today, a DHCP server [RFC2131] [RFC3315] provides 
a list of IP addresses for DNS resolvers (see Section 3.8 of 
[RFC2132]) but does not provide an authentication domain name for the 
DNS resolver, thus preventing the use of most of the authentication 
methods described here (all of those that are based on a mechanism 
with ADN; see Table 2). 


This document does not specify or request any DHCP extension to 
provide authentication domain names. However, if one is developed in 
future work, the issues outlined in Section 8 of [REC7227] should be 
taken into account, as should the security considerations discussed 
in Section 23 of [RFC3315]. 


This document does not attempt to describe secured and trusted 
relationships to DHCP servers, as this is purely a DHCP issue (and 
still open, at the time of this writing). Whilst some implementation 
work is in progress to secure IPv6 connections for DHCP, IPv4 
connections have received little or no implementation attention in 
this area. 


8. Credential Verification Based on Authentication Domain Name 
8.1. Authentication Based on PKIX Certificate 


When a DNS client configured with an authentication domain name 
connects to its configured DNS server over (D)TLS, the server may 
present it with a PKIX certificate. In order to ensure proper 
authentication, DNS clients MUST verify the entire certification path 
per [RFC5280]. The DNS client additionally uses validation 
techniques as described in [RFC6125] to compare the domain name to 
the certificate provided. 


A DNS client constructs one reference identifier for the server based 
on the authentication domain name: a DNS-ID, which is simply the 
authentication domain name itself. 


If the reference identifier is found (as described in Section 6 of 


[RFC6125]) in the PKIX certificate’s subjectAltName extension, the 
DNS client should accept the certificate for the server. 
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A compliant DNS client MUST only inspect the certificate's 
subjectAltName extension for the reference identifier. In 
particular, it MUST NOT inspect the Subject field itself. 


8.2. DANE 


DANE [RFC6698] provides various mechanisms using DNSSEC to anchor 
trust for certificates and raw public keys. However, this requires 
the DNS client to have an authentication domain name (which must be 
obtained via a trusted source) for the DNS privacy server. 


This section assumes a solid understanding of both DANE [RFC6698] and 
DANE operations [RFC7671]. A few pertinent issues covered in these 
documents are outlined here as useful pointers, but familiarity with 
both of these documents in their entirety is expected. 


Note that [RFC6698] says 


Clients that validate the DNSSEC signatures themselves MUST use 
standard DNSSEC validation procedures. Clients that rely on 
another entity to perform the DNSSEC signature validation MUST use 
a secure mechanism between themselves and the validator. 


Note that [RFC7671] covers the following topics: 


o Sections 4.1 ("Opportunistic Security and PKIX Usages") and 14 
("Security Considerations") of [RFC7671], which both discuss the 
use of schemes based on trust anchors and end entities (PKIX-TA (0) 
and PKIX-EE (1), respectively) for Opportunistic Security. 


o Section 5 ("Certificate-Usage-Specific DANE Updates and 
Guidelines") of [RFC7671] -- specifically, Section 5.1 of 
[REC7671], which outlines the combination of certificate usage 
DANE-EE (3) and selector SPKI(1) with raw public keys [RFC7250]. 
Section 5.1 of [RFC7671] also discusses the security implications 
of this mode; for example, it discusses key lifetimes and 
specifies that validity period enforcement is based solely on the 
TLSA RRset properties for this case. 


o Section 13 ("Operational Considerations") of [RFC7671], which 
discusses TLSA TTLs and signature validity periods. 


The specific DANE record for a DNS privacy server would take the form 
_853._tcp. [authentication-domain-name] for TLS 


_853._udp. [authentication-domain-name] for DTLS 
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8.2.1. Direct DNS Meta-Queries 


The DNS client MAY choose to perform the DNS meta-queries to retrieve 
the required DANE records itself. The DNS meta-queries for such DANE 
records MAY use the Opportunistic Privacy profile or be in the clear 
to avoid trust recursion. The records MUST be validated using DNSSEC 
as described in [RFC6698]. 


8.2.2. TLS DNSSEC Chain Extension 


The DNS client MAY offer the TLS extension described in 
[TLS-DNSSEC-Chain-Ext]. If the DNS server supports this extension, 
it can provide the full chain to the client in the handshake. 


If the DNS client offers the TLS DNSSEC chain extension, it MUST be 
capable of validating the full DNSSEC authentication chain down to 
the leaf. If the supplied DNSSEC chain does not validate, the client 
MUST ignore the DNSSEC chain and validate only via other supplied 
credentials. 


9 (D) TLS Protocol Profile 
This section defines the (D)TLS protocol profile of DNS over (D)TLS. 


Clients and servers MUST adhere to the (D)TLS implementation 
recommendations and security considerations of [RFC7525], except with 
respect to the (D)TLS version. 


Since encryption of DNS using (D)TLS is a greenfield deployment, DNS 
clients and servers MUST implement only (D)TLS 1.2 or later. For 
example, implementing (D)TLS 1.3 [TLS-1.3] [DILS-1.3] is also an 
option. 


Implementations MUST NOT offer or provide TLS compression, since 
compression can leak significant amounts of information, especially 
to a network observer capable of forcing the user to do an arbitrary 
DNS lookup in the style of the Compression Ratio Info-leak Made Easy 
(CRIME) attacks [CRIME]. 
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10. 


dl. 


Implementations compliant with this profile MUST implement the 
following items: 


o TLS session resumption without server-side state [RFC5077], which 
eliminates the need for the server to retain cryptographic state 
for longer than necessary. (This statement updates [RFC7858].) 


o Raw public keys [RFC7250], which reduce the size of the 
ServerHello and can be used by servers that cannot obtain 
certificates (e.g., DNS servers on private networks). A client 
MUST only indicate support for raw public keys if it has an SPKI 
pin set pre-configured (for interoperability reasons). 


Implementations compliant with this profile SHOULD implement the 
following items: 


o TLS False Start [RFC7918], which reduces round trips by allowing 
the TLS second flight of messages (ChangeCipherSpec) to also 
contain the (encrypted) DNS query. 


o The Cached Information Extension [RFC7924], which avoids 
transmitting the server’s certificate and certificate chain if the 
client has cached that information from a previous TLS handshake. 


Guidance specific to TLS is provided in [RFC7858], and guidance 
specific to DTLS is provided in [RFC8094]. 


TANA Considerations 
This document does not require any IANA actions. 
Security Considerations 


Security considerations discussed in [RFC7525], [RFC8094], and 
[RFC7858] apply to this document. 


DNS clients SHOULD implement (1) support for the mechanisms described 
in Section 8.2 and (2) offering a configuration option that limits 
authentication to using only those mechanisms (i.e., with no fallback 
to pure PKIX-based authentication) such that authenticating solely 
via the PKIX infrastructure can be avoided. 


Dickinson, et al. Standards Track [Page 21] 


RFC 8310 Usage Profiles for DNS over (D)TLS March 2018 


11. 


I2 


T2; 


1. Countermeasures to DNS Traffic Analysis 


This section makes suggestions for measures that can reduce the 
ability of attackers to infer information pertaining to encrypted 
client queries by other means (e.g., via an analysis of encrypted 
traffic size or via monitoring of the unencrypted traffic from a DNS 
recursive resolver to an authoritative server). 


DNS-over-(D)TLS clients and servers SHOULD implement the following 
relevant DNS extensions: 


o Extension Mechanisms for DNS (EDNS(0)) padding [RFC7830], which 
allows encrypted queries and responses to hide their size, making 
analysis of encrypted traffic harder. 


Guidance on padding policies for EDNS (0) is provided in 
[EDNS0-Pad-Policies]. 


DNS-over-(D)TLS clients SHOULD implement the following relevant DNS 
extensions: 


o Privacy election per [RFC7871] ("Client Subnet in DNS Queries"). 
If a DNS client does not include an edns-client-subnet EDNSO 
option with SOURCE PREFIX-LENGTH set to 0 in a query, the DNS 
server may potentially leak client address information to the 
upstream authoritative DNS servers. A DNS client ought to be able 
to inform the DNS resolver that it does not want any address 
information leaked, and the DNS resolver should honor that 
request. 
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Appendix A. Server Capability Probing and Caching by DNS Clients 


This section presents a non-normative discussion of how DNS clients 
might probe for, and cache capabilities of, privacy-enabling DNS 
servers. 


Deployment of both DNS over TLS and DNS over DTLS will be gradual. 
Not all servers will support one or both of these protocols, and the 
well-known port might be blocked by some middleboxes. Clients will 
be expected to keep track of servers that support DNS over TLS and/or 
DNS over DTLS, as well as those that have been previously 
authenticated. 


If no server capability information is available, then (unless 
otherwise specified by the configuration of the DNS client) DNS 
clients that implement both TLS and DTLS should try to authenticate 
using both protocols before failing or falling back to an 
unauthenticated or cleartext connection. DNS clients using an 
Opportunistic Privacy profile should try all available servers 
(possibly in parallel) in order to obtain an authenticated and 
encrypted connection before falling back. (RATIONALE: This approach 
can increase latency while discovering server capabilities but 
maximizes the chance of sending the query over an authenticated and 
encrypted connection.) 
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